For the purposes of redundancy, load sharing, operational policy or cost, a site may have connections to a communication network, e.g., the Internet, in a multi-homed fashion, with the site's network having connections to multiple Internet service providers (“SP”). In general, as is shown in FIG. 1, site multi-homing is a technique used to increase the reliability of an Internet connection for an organization, such as an Internet Protocol (“IP”) network 18 (e.g., Site Z), by connecting to multiple Internet SPs 14, 16 for the purposes of IP path redundancy. Site multi-homing is a growing trend in the Internet Protocol version 4 (“IPv4”) Internet and it is anticipated that this trend will continue. As the demand for site multi-homing increases, it creates a very serious route explosion addressing problem in the core of the Internet.
Routing table size has been a major issue for IPv4 networks, and is anticipated to be an even larger issue for Internet Protocol version 6 (“IPv6”) networks. As IPv6 addresses are 4 times larger in bit width, i.e., size, than IPv4, the routing table size issue in IPv6 networks has more serious negative effects on router memory usage, as well as routing table lookup performance. To cope with this problem, the IPv6 addressing architecture is designed to have the potential to take advantage of aggregated routing announcements to reduce the number of routes in the default-free zone (“DFZ”). Also, the IPv6 backbone (“6bone”) operation guideline (which is the currently-practiced guideline for IPv6 network operation) suggests that Autonomous Systems (“AS”) withhold announcing non-aggregatable announcements to the default-free zone, unless there is a special agreement with the peer.
In IPv4, a multi-homed site uses either of the following techniques to achieve better reachability—(1) obtain a portable IPv4 address prefix, and announce it from multiple upstream providers; or (2) obtain a single IPv4 address prefix from a first SP (e.g., SPA 14) and announce it from multiple upstream providers to which the specific site is connected. Since the above two methodologies effectively inject additional routes to the worldwide routing table, they have a negative impact on the worldwide routing table size issue. In addition, the two methodologies also are not compatible with current IPv6 operational goals.
When a site is allocated its IP address, generally it comes from its SP's block of addresses and is commonly referred to as Provider Allocated (“PA”) addressing. FIG. 2, illustrates this situation where the SPA 14 advertises addresses to its peers 12, 16 by advertising a single aggregate route address, 130.55/16. In this example, Site Z's 18 specific individual site address, 130.55.7.X does not have to be advertised by SPA 14 because this address is included in the aggregate route address. Aggregate route addressing reduces the routing and forwarding tables in the core of the Internet and keeps “address churn” to a minimum. As the transition to IPv6 occurs, the aggregation ratio may reach as high as 64,000 to 1 (64K:1) for a single SP.
Currently, Internet routing infrastructure permits multi-homing by using provider independent (“PI”) addressing, and adapts to changes in the availability of these connections. An example of the PI addressing is illustrated by the system 10 in FIG. 3. Several drawbacks of the PI addressing scheme are no aggregation of PI addresses, it is a temporary solution, it is a nonscalable solution, and pursuant to a American Registry for Internet Numbers (“ARIN”) policy, only very large sites are permitted to obtain PI addresses, and thus it fails to support the thousands of smaller sites desiring multi-homing capability.
Another proposed solution is the use of site multi-homing by IPv6 intermediation (“Shim6”), which is a host-to-host based protocol where the site has a PA prefix from each upstream SP and each host derives addresses from each of these prefixes. The host then negotiates with the far end of the connection to establish failover protection. If there is a failure, the host uses the alternate address for all active and new sessions. Shim6 is fairly controversial and has not been widely accepted by the Internet community as Shim6 presents numerous problems including forcing servers to retain large amounts of state tables in order to maintain site multi-homed connections; significantly increases each host's complexity and thereby results in increased service calls to service providers; lacks centrally controlled traffic engineering, increases the difficulty in setting up filters and security when an address changes, and requires both ends of route to be Shim6 capable which results in a site not having full control of its redundancy policy.
Request for comments (“RFC”) 3178 describes another proposed site multi-homing solution involving a tunneling method that provides tunneling back to the primary service provider (“SP”) through a secondary SP in the case of a failure. This solution has been available for IPv4 since 2001, however, it is rarely if ever used. Many in the IP networking community view this “solution” as being too complicated to establish, as well as maintain, for both the SP and user. In addition, it does not provide comprehensive coverage for all failure cases, and the failure path can add significant latency to a connection. The RFC 3178 solution will basically have the same issues when applied to IPv6 that it does when applied to IPv4.
Although, the Border Gateway Protocol (“BGP”) currently allows routes to be aggregated, it is a completely manual policy configuration process. There is no information in routing advertisements that allows for any automation and therefore the lack of automation or auto routing presents several problems, such as operators requiring very detailed network information about aggregate prefixes advertised throughout the Internet, but this information is changing constantly as SPs are added and/or deleted. Moreover, there are large numbers of complex policies which must be configured and the routing calculations (convergence) slows down as the number and complexity of policies increases and any incorrect policy can cause misrouting.
What is desired is an arrangement under which multi-homing can be fully implemented without significant impact on the worldwide routing table size, or the interior gateway protocol (“IGP”) routing table size of upstream Internet SPs.